クラウドの基本機能を解説（AWS , Google Cloud）
初めに
よくIT初心者の方やクラウドをよく知らない方から、クラウドってiCloudの事でしょ？とかGoogleドライブの事でしょ？などと聞くことがありました。
確かにこれも間違えではないのですが、この二つはクラウドの一部に過ぎず、クラウド＝SaaSのクラウドストレージと理解している方が多いのかな、とこれまで聞いた中で感じました（私だけかもですが）。
よって今回はクラウドを勉強している方やある程度クラウドとはなんだろうと理解したい方に向けて、Google Cloud（旧GCP）とAWSを例に挙げながら、基礎的な用語や概念を解説して行こうと思います。
前回解説した記事も参考になるかと思います。短いのでさらっとお読みください。
【IaaS PaaS SaaSの違いをざっくり解説（初心者歓迎）】
VPCネットワーク
仮想的なネットワークアドレスの範囲を定義するリソースとなります。（リソース＝クラウド内で使うサービス）
基本的にどのクラウドにも、VPCネットワークという概念は存在しているのですが、役割はクラウドごとで異なることがあります。（同じVPCというサービスだが仕様が違う）
2つのクラウドを例に挙げて考えてみましょう。
AWSのVPCネットワーク
AWSとAzureのVPCネットワークの構造は似ています。
まずはVPCにIPアドレスの範囲を指定し、その範囲内でサブネットを作成し、さらにそのサブネットにIPアドレス範囲を定義していきます。
画像の解説
まず、VPCネットワークに192.168.0.0/16という大きなアドレス範囲を払い出し、さらにその範囲内に収まる192.168.1.0/24と192.168.2.0/24を定義しています。（VPCのアドレス範囲より大きい範囲をサブネットに指定することはできません）
また、東京リージョン内でVPCとサブネットは作成されていて、その他のリージョン（大阪リージョンや海外リージョン全て）をまたがってVPCやサブネットを作成することはできません。
あくまでも、AWSでのVPCは単一リージョン内でのみ定義できるリージョンリソースだと理解して下さい。
さらに、サブネットはリージョン内にあり単一のゾーンのみに定義できるものでゾーンリソースと呼ばれます。
このあたりのネットワーク構造の知識は資格試験でもポイントになりますので、ぜひ覚えて下さい。
次に、その比較対象としてGoogle CloudのVPCネットワークの解説をしていきます。
Google CloudのVPCネットワーク
Google CloudのVPCネットワークはクラウドの中では特徴的です。
ネットワークの特徴などは以前の記事を参考にして下さい。
【Google Cloud：ネットワーク関連の特徴【前編】】
簡単に解説すると、Google CloudのVPCにはIPアドレスの範囲を指定しません。
アドレスの範囲を指定するのは、その次のレイヤーにあたるサブネットになります。ここがAWSのネットワーク構造との大きな違いになります。
よって、VPCは単なるサブネットを囲う大きな枠（箱）としての役割に過ぎず、作成時に何かしらのパラメーターを作成することはありません。
ただし、このVPCの中に存在する機能がとても豊富にあり、Google Cloudの要のサービスと言っても過言ではありません。
画像の解説
まずはグローバルリソースという単語を覚えて下さい。
グローバルリソースとは、世界全体（全てのリージョン）で定義できるという意味でGoogle Cloudのみの特徴となります。
これを実現できるのは世界中に張り巡らされたケーブルが物理的にリージョンを繋いでいるためにできることです。また、日本とカナダを結ぶ海底ケーブルなども複数存在するため、Googleのサービス自体を構成するネットワーク規模だからこそ出来ることなのです。
私も勉強したてはイメージがつかなかったのですが、単純に糸電話のように繋がっているイメージを持って下さい。
以上を踏まえた上で画像を解説すると、AWSでは東京リージョンの枠が1番外側だったのに対し、Google CloudではVPCの枠が1番外側で全てを囲んでいます。
これの意味としては、1つのリージョン単位ではなく、複数または何十ある全てのリージョンを跨いでVPCを構築することができるのです。
メリットとしては、VPCの管理が楽になったり、1つのファイアウォールルール（通信する際のルール）で共通したネットワーク管理が可能となるのです。 この辺に関しての説明はもっとありますが、今回はグローバルVPCという単語の理解をして頂ければ十分です。
VM
VM（バーチャルマシン）は、企業がオンプレミスからクラウドに移行する手始めの選択肢として選ばれることが多いです。
クラウドとは、そもそもデータセンター内のリソースをクラウド事業者に借りることで成り立っています。（それは違う!!と言われそうですが、ニュアンス的にはこのイメージがしっくりくると思います）
よって、もともと自社企業内でアプリやWebサービスを運営していた企業であれば、同じような環境をすでに持っているはずです。（もちろん規模は違う）
自社のデータセンター → クラウドのデータセンター を選ぶ理由には多くのメリットがあるからこそ、クラウドへの移行を選択するはずです。
その中で、VMというのは自社データセンターから1番移行しやすいものとなっています。
ここからは、Google Compute Engineを例にVMを解説していきましょう。
Google Compute Engine（GCE）
GCEは先に解説したGoogle CloudのVMサービスです。
仕組みとしては、クラウド事業者のデータセンター内にあるサーバーを遠隔（Webなど）から操作することにより、自分専用のVM（サーバー）を作成/利用することが可能です。（物理的サーバー1つを丸々借りる訳ではないので注意）
本来、自社でサーバーを運用するとなると、初期コストや運用コストなどそのサーバー1台に対する様々なコストとリスクが表れてくるため、オンデマンド（リアルタイム）で利用したい時に最短数十秒でVM（サーバー）を構築できるのは大きなメリットの1つです。
実際のGCE作成画面
実際のVMを作成する画面を見てみましょう。
Gif画像なので少し荒いですが、イメージは掴めると思います。
このようにGCE（VM）に必要な項目を上から順に設定していきます。
【基本設定】
- リージョンとゾーンの選択
- リージョン：国（都市）を選択する
- ゾーン：リージョン内に存在するアルファベット(a~cなど)のゾーンを選択する
- マシンの構成
- マシンシリーズ：E2,N2,C2,M3などそれぞれのアルファベットによりVMの機能が異なる
- マシンタイプ：メモリとCPUの性能の違い（大きければ料金は高価になる）
- ブートディスク
- GCEとセットで作成するOSが格納されているストレージ（PDともいいます）
- 詳細オプション(ネットワークの項目のみ説明)
- サブネットを作成or既存のサブネットを選択し、その中にGCEを配置していきます
GCEまとめ
基本的にGCEなどのVMはサブネットの中に作成していきます。これはどのクラウドでも共通することなので、覚えておきましょう。
IAM
こちらは、Identity Access Managementの略で、クラウドの代名詞と言ってもいいかも知れません。
このIAMというのはいわば、ユーザー認証に付随してアクセスを制御します。
よって、Google Cloudを使うときにも、作成したVMにアクセスする時にも、PaaSサービスのApp Engineにアクセスする時にも全てIAMが関わってきます。
とても奥が深い分野なので全てを説明することはできませんが、とりあえず簡潔に図にしてみました。
画像の説明
Google Cloud内のサービスを使用するにはCloudコンソールにアクセスしなければいけません（Google Cloudのウェブサイトのようなイメージ）。
その時に、ユーザーAが事前に定義されたIAM情報を持っていき、Cloudコンソールにログインする際にユーザー情報（＝認証）を打ち込み、ログインします。
（例） maccho_taro@camil.com → メールアドレスがユーザーID
ただ、このログイン時にはすでにAさんが操作できる情報（＝認可）が決められていて、その範囲しか操作できないのです。
それが画像で言うところの、BQ（Big Queryというサービス）にはアクセスできず、GCS（Google Storage Service）とSQL（CLoud SQL）にはアクセスできるという事で表現をしています。
（例） maccho_taro@camil.com → 認可情報（GCS→○、BQ→×、SQL→○）
これがゼロトラストセキュリティという現在主流のネットワーク構築方法と密接に関わり合ってきます。
こちらについては、以前にIT未経験者でもわかるようにブログにしているのでご覧ください。
【Google Cloud：ゼロトラストについてIT未経験者向けに解説します】
ストレージ
Google Cloud StorageとAmazon S3
データを保存する（溜める）役割を持つCloud Storageについて解説します。
通称データレイクなどと言われることもある、まさにデータをとりあえず保存したいときにうってつけのサービスです。
このとりあえずというのが結構重要で、データの形式が定まっていないと保存できないサービスが多々あります。
（例） Cloud SQL、Amazon RDS...etc → 構造化データ(表形式など)のみ扱える
Cloud Storage（Google Cloud）では、どんな形式のデータでも保存できるのです。（表形式、テキスト、画像、動画...etc）
さらに、この開発者側が触るS3やCloud Storageはデータの保存料金が安いといった特徴も、どのクラウドベンダでも比較的共通するものなので覚えておきましょう。
例えば、皆さんがよく知るiCloudやDropBoxのようなSaaSのストレージサービスでも、このCloud StorageやS3などのサービスが裏では動いていると思います。（AWSかGCPかその他クラウドベンダのサービスかは分かりません）
また、Cloud Storageとクラウドストレージを使い分けたのには理由があり、Cloud StorageはGoogle Cloudのサービス（以下GCS）になります。
一方で、クラウドストレージと表現したものは、全てのストレージサービスを含ませるためです。（iCloud、DropBox、S3、Cloud Storage...etc）
つまり、iCloudのようなサービスとしてユーザーに提供するストレージが、普段皆さんも使うサービスとしてのストレージであり、そのサービスを開発するために触るストレージがS3やGCSであるということになります。
画像の説明
左側が開発者が触るAWSやGoogle Cloudで利用するStorageサービスなのに対し、右側はそのストレージサービスで作成/開発したユーザーが使用するストレージサービスとなります。
クラウドストレージという表現は、このように解釈次第でどちら側とも取れるかと思います。
非エンジニアの方へ簡単な理解方法をお教えするのであれば、サービスとして使用するだけのストレージは普段から使うもの、その裏で動いている開発者用のサービスがS3やGCSなどのStorageサービスだと覚えるといいかも知れません。
まとめ
以上がクラウドを勉強し始めた方や試験勉強でなんとなくVPCやIAMの概念が分かりずらい、と言った方に向けた記事になります。
私のイメージだと、クラウドを学習する上でIT全般の基礎知識があれば、結構すんなりと内容が入ってくるような気がします。
ただ、分野とサービスとクラウド種類といった量が膨大すぎるので、とりあえず1つのクラウドに集中して学習をしてITの基礎も並行して勉強することをおすすめします。 不明な箇所はコメントください。
最後に
前職が元パーソナルトレーナーであったため、ダイエット情報や筋トレ情報を積極的に配信したいと思っています！！IT＝脳＝運動＝体調管理⇒全ては繋がっています。
同じトレーニングを毎日してはいけない
今回は怪我予防の観点からお話します。
なぜ毎日同じトレをしてはいけないか？？ 一言でお伝えすると、「関節を壊さない」ことが目的です。
関節は一度故障してしまうと、なかなか治りずらく、怪我の癖などもついてしまう可能性があります（脱臼癖などのように）
筋肉は大丈夫でも骨と骨をつないでいる関節は脆く壊れやすいです。
ですから、筋肉痛がない、疲れがないからといって連日同じようなトレーニングをしてしまっては、関節がその強度/負荷に耐えられず、怪我につながってしまいます。
これはアスリートでも同じです。
一度の怪我で１ヶ月、２ヶ月トレーニングを休まなければならないといった状況は最悪です。
少なくとも、同じ部位のトレーニングは2日以上は期間を空けましょう。（負荷によるが理想は3~4日明ける頻度）
